Appln.No.: 09/988,002 
Amendment dated November 1, 2004 
Reply to Office Action of September 7, 2004 

REMARKS/ARGUMENTS 

The Office Action of September 7, 2004 has been carefully reviewed and these remarks 
are responsive thereto. Reconsideration and allowance of the instant application are respectfully 
requested based on the following arguments. 

Claims 1-4, 10-15, 18-21,23-25, 27-28,35, 48-51, and 57-62 stand rejected under 35 U.S.C. 
§ 103(a) as being unpatentable over mValue in view of Blasko (U.S. Publ. Appl No. 2001/0049620 
Al). Each reference is briefly described below, and this rejection is respectfully traversed for the 
following reasons. 

mValue describes an unsuccessful effort to pay Internet users to view advertisements and 
"surf 5 the Internet. Users using mSurf earn cash and mValue points while online and surfing the 
Internet. Users can also be paid by advertisers for the release of personal information, such as an 
email address or surfing history, using mValue's mExchange service. Finally mValue's 
mPrivacy service allows a user to selectively block companies that make information requests 
from "cookies" stored on the user's computer system. 

Blasko, on the other hand, describes a method and system for transaction profiling in a 
privacy protected manner. Blasko, Abstract. The Blasko system computes a transaction profile 
vector based on an evaluation of a completed transaction. The profile vector computes 
information based on a recorded transaction, and includes information such as probable age, 
household size, income level, or preference attributes indicating probable products and services 
preferred by the user. Blasko, Abstract. Thus, Blasko analyzes a completed transaction, makes 
assumptions as to certain characteristics of a user that is a party to the transaction, and populates 
a profile vector based on those assumptions. 

In order to reject a claim as obvious under § 103(a), three criteria must exist: 1) there 
must be some suggestion or motivation, either in the references themselves or in the knowledge 
generally available to one of ordinary skill in the art, to modify the reference or to combine the 
reference teachings; 2) there must be a reasonable expectation of success; and 3) the prior art 
reference(s) must teach or suggest all the claim limitations. See MPEP § 706.02 (j); In re Vaeck, 
947 F.2d488 (Fed. Cir. 1991). 
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The rejection should be withdrawn because there is neither a motivation to combine the 
references nor a reasonable expectation of success even if the references are combined, nor 
would the references, even if combined, teach or suggest all the claim limitations. Each of these 
arguments is addressed in turn below. 

Lack of Motivation to Combine the References 

The Office Action states that it would have been obvious to combine the master profile 
and plurality of service profiles, and the user selection of a service profile as corresponding to a 
second party, as allegedly described in Blasko, with mValue "for the advantage of providing a 
method (system, mobile device, computer readable medium) for controlling access, use and 
distribution of personal data of a user stored in a personal data repository, with the ability to 
increase system/method effectiveness by allowing the user to select what companies they wish to 
interact with and how they wish to interact with them." Office Action, ^| 7. Even if the 
combination provided such a feature (which applicants maintain it does not, as further discussed 
below), this is not a motivation to combine the references, but is instead an end-result of the 
combination. The Office Action has pointed to nothing in the references that actually suggests 
they may be combined in any way, and instead uses the alleged result of the combination as the 
motivation to combine mValue and Blasko in the first place. This is improper hindsight 
reasoning. Put another way, the Office Action has pointed to nothing in either reference 
suggesting their combination or that there is some advantage in providing a method as claimed. 
Applicants submit that the advantages of the present invention could not have been appreciated 
without first having read Applicants' disclosure, much less using Applicants' disclosure as a 
basis for combining the references 

Indeed, the Federal Circuit has repeatedly stated that the limitations of a claim in a 
pending application cannot be used as a blueprint to piece together prior art in hindsight, In re 
Dembiczak, 50 U.S.P.Q.2d 1614 (Fed. Cir. 1999), and that the Patent Office should rigourously 
apply the requirement that a teaching or motivation to combine prior art references needs to be 
provided. Id. (emphasis added). Thus, Applicants respectfully submit that that there is no 
motivation or suggestion to combine mValue with Blasko. Blasko in fact teaches away from 
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mValue at para. [0051] by stating "the user's private information is not sold/made available to 
third parties," whereas it is a stated purpose and goal of mValue to sell user information to third 
parties. 

No Reasonable Expectation of Success 

Even if one improperly combines mValue and Blasko, there is no reasonable expectation 
of success in the combination. A stated purpose of mValue is to sell user information to third 
parties, but with the approval of the user, and with at least partial payment going back to the 
user. Blasko, on the other hand, calculates profile vectors from transactions that are already 
completed, and even then Blasko uses probabilities to create profile vectors based on the 
transaction. There is no guarantee that the information in the profile vector is actually user 
information. Blasko states that it uses conditional probabilities to create profile vectors, and that 
Blasko statistically applies a determination of transaction data to obtain probabilistic profile 
vectors. Blasko, at [0047]. Blasko even goes so far as to state that any personal information is 
discarded. Blasko, at [0051]. One must ask: if Blasko discards all actual user information, 1) 
how can Blasko then submit a service profile of user information to a third party, and 2) how can 
the user select a service profile of user information to submit to a third party. The answer: 
Blasko does neither. In view of the above two limitations of Blasko, there is no reasonable 
expectation of success in an improper combination of mValue and Blasko. In addition, as 
indicated above, Blasko does not sell or other make a user's private information available to third 
parties, and thus the system described by Blasko teaches away from and could not work with the 
system of mValue. 

The Combination Would Not Teach or Suggest All the Claim Recitations 

As with the Expectation of Success prong discussed above, even if mValue and Blasko 

are improperly combined, the resulting combination would not teach or suggest all the claim 

recitations. Claim 1 recites, inter alia: 

a data processing device receiving input defining personal 
data comprising a master profile and a plurality of service profiles 
for storage in a digitally stored personal data repository, the master 
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profile and plurality of service profiles providing information 
about only a single user; 

receiving user input identifying one of the plurality of 
service profiles stored in the personal data repository as 
corresponding to a second party; 

The Office Action relies on Blasko as describing a master profile and a plurality of 
service profiles, and also for receiving user input identifying one of the plurality of service 
profiles as corresponding to a second party. Office Action, f 6. Blasko, however, describes 
neither. 

The profile vectors of Blasko are not service profiles as claimed. A service profile 
includes information that the user wants to share with one or more other parties, and may contain 
information that a user wants to share with only one party, e.g., a bank. Application as filed, f 
[35]. The profile vectors of Blasko do not include information that the user wants to share with 
the third party, but instead include probabilistic information based on a completed transaction, 
and are generated after the transaction with the third party is complete, i.e., the user has already 
provided other information to the third party. 

In addition to the above, in Blasko the user never selects a profile vector as 
corresponding to a third party. The user makes no selections with respect to profile vectors. 
This is evident from Blasko 's repeated affirmations that personally identifiable information 
about a user is discarded, and that user information is not sold or made available to third parties. 
Blasko, f [0051] -[0052]. Even if a profile vector is associated with a party to a transaction, that 
association is not made by the user (i.e., it is not the result of "user input" as recited in claim 1), 
but by the automated software system implementing the profile vector heuristics. 

Thus, claim 1 is allowable even if mValue and Blasko are improperly combined because 
the resulting combination does not teach or suggest a plurality of service profiles, nor does the 
combination teach or suggest a user selecting a service profile as corresponding to a second 
party. 

Independent claim 18 is allowable for similar reasons as claim 1, namely, that neither 
mValue nor Blasko teach or suggest said personal data comprising a master profile and a 
plurality of service profiles as claimed. 
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Independent claim 25 is allowable for similar reasons as claim 1 , namely, that neither 
mValue nor Blasko teach or suggest a data storage, associated with the user device, storing 
personal data of only the single user, said personal data comprising a master profile and a 
plurality of service profiles, as claimed. 

Independent claim 35 is allowable for similar reasons as claim 1, namely, that neither 
mValue nor Blasko teach or suggest a data storage device storing at least some personal data of 
only the single user, said personal data comprising a master profile and a plurality of service 
profiles, as claimed. 

Independent claim 48 is allowable for similar reasons as claim 1, namely, that neither 
mValue nor Blasko teach or suggest receiving input defining personal data comprising a master 
profile and a plurality of service profiles for storage in the personal repository, the master profile 
and plurality of service profiles corresponding to only the single user; and receiving user input 
identifying one of the service profiles stored in the personal data repository as corresponding to a 
second party, as claimed. 

Claims 2-4, 10-15, 19-21, 23, 24, 27, 28, 49-51, and 57-62 are allowable for all the 
reasons given above concerning their respective base claims, and further in view of their specific 
recitations that have not been shown to be in (or obvious from) the prior art. 

In addition, the improper combination of Blasko and mValue does not teach or suggest 
all the recitations of any of claims 10-12, 57 and 58 because there are no service profiles in either 
mValue or Blasko. 

With respect to claims 14, 15, 19-21, and 24 the Office Action makes a conclusory 
rejection without providing support in either mValue or Blasko. In the event the rejection is 
maintained, the examiner is requested to cite supporting evidence, as required by MPEP § 
2144.03. 

With respect to claims 27, 28, 49-51, and 57-62, while the Office Action lists these 
claims in the rejection header in If 3, the Office Action does not discuss these claims in the 
detailed portion of the rejection flfU 4-25 of the Office Action). Thus, Applicants are afforded no 
fair opportunity to respond to the rejection with respect to these claims, and Applicants 
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respectfully request the Examiner either allow the claims, or cite supporting evidence for the 
rejection of these claims as required by MPEP § 2144.03 in a subsequent Office Action. 

Claims 5-9, 22, 26, and 52-56 also stand rejected under 35 U.S.C. § 103(a) as being 
unpatentable over mValue in view of Blasko. Each claim is allowable over mValue and Blasko 
at least for the same reasons discussed above with respect to motivation to combine, expectation 
of success, and also because each is based on an allowable base claim. 

In addition, the Office Action states that claims 5-9, 22, 26, and 52-56 include only 
functional descriptions that cannot patentably distinguish the claims over the prior art. Office 
Action, TflJ 28, 31, and 34. However, the Office Action misapplies the legal precedent on which 
it relies. The bare presence or absence of a specific functional relationship is not dispositive of 
obviousness. In re Gulack, 217 U.S.P.Q. 401, 404 (Fed. Cir. 1983). The examiner argues that 
"descriptive material will not distinguish the claimed invention from the prior art in terms of 
patentability." Office Action, ^| 28, 31, and 34. However, the court in Lowry specifically states that 
"the printed matter cases have no factual relevance where the invention as defined by the claims 
requires that the information be processed not by the mind but by a machine, the computer." In re 
Lowry, 32 U.S.P.Q.2d 1031, 1034 (Fed. Cir. 1994) (quoting In re Bernhart, 163 U.S.P.Q. 61 1, 615 
(CCPA 1969)). The examiner cannot simply ignore claim language. Thus, the examiner has not 
made a prima facie case of obviousness for these claims over mValue and Blasko because the 
combined references do not teach or suggest all the claim limitations as admitted in the Office 
Action. 

Claim 45 stands rejected under 35 U.S.C. § 103(a) as being unpatentable over mValue. 
However, mValue does not teach or suggest a mobile device. In addition, mValue does not state 
that mobile devices are even supported, as mobile devices require different software versions 
than are necessary for use on a desktop or laptop computer. In addition, claim 45 recites "the 
history recorder including a level selector to select a level of the actions to be recorded." This is 
different from the alleged satisfying aspect of mValue, that a user can select a price and type of 
information to provide to companies. Regardless of what the user decides to record, the user 
may arbitrarily decide something different to provide to companies. Thus, this rejection is 
respectfully traversed. 
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CONCLUSION 



It is believed that no fee is required for this submission. If any fees are required or if an 
overpayment is made, the Commissioner is authorized to debit or credit our Deposit Account No. 
19-0733, accordingly. 

All rejections having been addressed, applicants respectfully submit that the instant 
application is in condition for allowance, and respectfully solicit prompt notification of the same. 
However, if for any reason the Examiner believes the application is not in condition for allowance 
or there are any questions, the examiner is requested to contact the undersigned at (202) 824- 



3153. 



Respectfully submitted, 



BANNER & WITCOFF, LTD. 



Dated this J_ day of Mo* » 2004 



By: 




Ross DannenbergrR-egrslnraon 
1001 G Street, N.W. 
Washington, D.C. 20001-4597 
Tel: (202) 824-3000 
Fax: (202) 824-3001 



RAD/mmd 
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